This chapter describes how to use the Frame Relay interface and includes the following sections:
The Frame Relay (FR) protocol is a method of transmitting internetworking packets by combining the packet switching and port sharing of X.25 with the high speed and low delay of time division multiplexing (TDM) circuit switching. FR allows you to connect multiple LANs to a single high-speed (1.54 Mbps) WAN link with multiple point-to-point virtual circuits (VCs). FR offers the following features:
The router can also initiate a slowdown of traffic when it receives a Consolidated Link Layer Management (CLLM) congestion message. CLLM is an optional part of the Frame Relay standards that provides additional management information about the operation of the frame relay network to attaching DTEs.
FR provides no error correction or retransmission function. To provide error-free end-to-end transmission of data, FR relies on the intelligence of the host devices.
The FR network consists of the FR backbone (consisting of FR switches provided by the FR carrier) providing the FR service. The router functions as the FR connection device. The router encapsulates FR frames and routes them through the
network based on a Data Link Connection Identifier (DLCI). The DLCI is the medium access control (MAC) address that identifies the PVC or SVC between the router and the FR destination device. For example, in Figure 21, a packet destined to go from router B to router D would have a DLCI of 19 to reach router D; however, a packet destined to go from router D to router B would have a DLCI of 16.
Figure 21. DLCIs in Frame Relay Network
A DLCI can have either local or global significance. Local DLCIs are significant at the point of entry to the network, but global DLCIs are significant throughout the network. To the user, however, the DLCI that the router uses to route a packet is the DLCI that the user associates with the frame's global or local destination. DLCIs are configured through the FR configuration process or learned through FR management.
FR PVCs are predefined connections used to route data through a FR network. The bandwidth allocated for a PVC within the network is a subscription option and must be allotted to the PVC whether or not the PVC uses it.
A Frame Relay network has the following characteristics:
Frame Relay Switched Virtual Circuits (SVCs) provide the ability to implement "cut-through" routing in a Frame Relay network, minimizing or eliminating intermediate router hops between DTEs. Network complexity can be simplified and the DTE may experience improved performance.
SVCs may replace PVCs to conserve network bandwidth, reducing bandwidth cost.
FR SVC standards are a subset of ISDN standards and provide many of the same advantages as ISDN with less complexity.
The following protocols are supported over FR SVCs:
SVCs cannot be required and cannot belong to a required group.
Local Management Interface (LMI) is used to determine the status of PVCs on a Frame Relay interface. If an LMI is enabled, the FR interface is active when a successful exchange of LMI frames occurs between the router and the FR switch; however, no data can be received from or transmitted to another router until an LMI status message indicates that the PVC status for the DLCI to the other router is active. Also, there are instances where the FR interface state is tied to PVC states and the interface does not come up even if LMI or Q.922 exchanges are successfully occurring (for additional information, see "Configuring PVC States to Affect the Frame Relay Interface State").
If LMI is not enabled and SVCs are enabled, the Frame Relay interface is active when a successful exchange of Q.922 frames occurs between the router and the adjacent device. All PVCs are considered active at this point. However, SVCs are active only after a successful Q.933 activation exchange.
PVC status appears for all PVCs as either active or inactive. An active PVC has a completed connection to an end system. An inactive PVC does not have a completed connection to an end system because either an end system or an FR switch is off-line.
For example, in Figure 22 router B has a configured PVC to router D. Router B is successfully interacting with FR management through FR switch B. Because either another FR switch is down or the end system is down, the end-to-end PVC connection is not established. Router B receives an inactive status for that PVC.
Figure 22. DLCIs in Frame Relay Network
When the LMI and SVCs are disabled, the FR interface is running on a serial line and a DTE cable is being used, the FR protocol asserts the DTR and RTS modem control signals. (The Control signal is asserted for X.21). The FR interface goes up once the DSR, CTS, and DCD modem control signals are on. (When X.21 is used, the FR interface goes up once the Indication modem control signal is on.) The FR interface is down or in the testing state if either DSR, CTS, or DCD are off or, when X.21 is used, the Indication signal is off. Therefore, you need to ensure that the modem, modem eliminator, or DSU that is used drops one or more of these signals when the physical connection to the FR switch or the other FR DTE (if configured for FR DTE to DTE connectivity) is lost.
An orphan permanent virtual circuit is any PVC that is not configured for your router but is learned indirectly through the actions of the network management entity. For example, Figure 23 assumes that router B has a configured PVC to router D, but none to router A. Router A configures a PVC to router B. Router B would then learn about the PVC to router A from LMI messages and classify it as an orphan.
Orphan PVCs are treated the same as configured circuits except that you may enable or disable their use with the enable orphan-circuit and disable orphan-circuit commands.
By disabling orphan circuits, you add a measure of security to your network by preventing any unauthorized entry into your network from a non-configured circuit. By enabling orphan circuits, you allow the router to forward packets over circuits you did not configure. Packets that would normally be dropped are now forwarded.
An orphan switched virtual circuit is an SVC that is not configured for your router but is created when a call-in is received for it. This is similar to Figure 23. However, Q.933 messages are used instead of LMI to generate the circuit and associate the appropriate parameters with it. Orphan SVCs are treated the same as configured SVCs except that you may enable or disable their use with the call-in option of the enable switched-virtual-circuit command.
You can control the operation of your Frame Relay interface by
By enabling the Frame Relay "No-PVC" feature, the Frame Relay interface becomes inactive when there are no active PVCs on the interface. If at least one PVC is active, the Frame Relay interface becomes active when a successful LMI exchange occurs between the router and the FR switch.
You can configure a PVC as a "required PVC". If a PVC is required but not in a group, the Frame Relay interface becomes inactive when the PVC becomes inactive. When the PVC becomes active, the interface is activated following a successful exchange of LMI frames between the router and the Frame Relay switch.
If multiple PVCs are required and are not in a PVC group, the interface is not activated until all required PVCs are active.
If a required PVC belongs to a PVC group, the Frame Relay interface becomes inactive when all PVCs in the PVC group are inactive. If at least one PVC in the group is active, the interface becomes active following a successful exchange of LMI frames between the router and the FR switch. If there are multiple PVC groups, the interface does not become active until at least one PVC in each group is active.
A "required PVC group" is a group of circuits associated by name, where "name" is the name of the required PVC group.
These features can be used with WAN Reroute so that an alternate link can be brought up if all PVCs, required PVCs, or a group of PVCs become inactive on the primary FR link.
An FR frame consists of a fixed size address field with variable sized encapsulated user data. Figure 24 illustrates a Frame-Relay frame format.
Figure 24. Frame-Relay Frame Format
8 7 6 5 4 3 2 1
Octet *---------------------------------------------*
1 | HDLC Flag = 0x7e |
*-----------------------------------*----*----*
2 | Data Link MSB/LSB (DL) |C/R | EA |
*-------------------------*----*----+----+----*
3 | Connection ID (CI) |FECN|BECN| DE | EA |
*-------------------------*----*----*----*----*
* *
. user .
. data .
. .
* *
*---------------------------------------------*
| Frame Check |
*---------------------------------------------*
| Sequence |
*---------------------------------------------*
N | HDLC Flag = 0x7e |
*---------------------------------------------*
Located in the first and last octet, these flags indicate the beginning and end of the frame.
This 10-bit routing ID resides in bits 3 to 8 of octet 2 and bits 5 to 8 of octet 3. The DLCI is the MAC address of the circuit. The DLCI allows the user and network management to identify the frame as being from a particular PVC. The DLCI enables multiplexing of several PVCs over one physical link.
This field's use is not defined within the Frame-Relay standards and the field is passed transparently across the network.
This version of FR does not support extended addressing.
The FR backbone network sets this bit to 1 to notify the user receiving the frame that congestion is occurring for the PVC in the direction the frame is being sent. You can configure the device to slow down data transmission in the direction from which it receives a FECN using the enable throttle-transmit-on-fecn command. You can also set the BECN bit in data frames sent to the originator of the FECN using the enable notify-fecn-source command.
APPN High Performance Routing (HPR) uses detection of this bit set to allow Rapid Transport Protocol's adaptive rate-based flow and congestion control algorithm to adjust the data send rate. This algorithm prevents traffic bursts and congestion, maintaining a high level of throughput.
The FR backbone network sets this bit to 1 to notify the user that the frames sent by this router for this PVC have encountered congestion. The router then initiates a throttle down to a rate equal to or less than the user-defined CIR when CIR or congestion monitoring are enabled. The CIR for a PVC is supplied by the FR service provider and is configured using the add permanent-virtual-circuit command.
The Frame Relay network may discard transmitted data exceeding CIR on a PVC. The DE bit can be set by the router to indicate that some traffic should be considered discard eligible. If appropriate, the Frame Relay network will discard frames marked as discard eligible which may allow frames that are not marked discard eligible to make it through the network. To identify traffic that is discard eligible:
This field contains the protocol packet being transmitted. This field can contain a maximum of 8188 octets; however, the frame check sequence (FCS) can effectively detect errors only on a maximum of 4096 octets of data. The protocol data is preceded by a Frame Relay encapsulation header as defined in RFC 1490 and RFC 2427.
This field is the standard 16-bit cyclic redundancy check (CRC) that HDLC and LAPD frames use. This field detects bit errors occurring in the bits of the frame between the opening flag and FCS.
When the FR protocol receives a packet for encapsulation, it compares the packet's network address to the entries in the address resolution protocol (ARP) cache. If the ARP cache contains the DLCI number that matches the network address, the FR protocol encapsulates that packet into a frame and transmits the frame over its specified local DLCI. If the ARP cache does not contain a match, the FR protocol sends out an ARP request over all configured PVCs on the interface. When the appropriate end-point responds with an ARP response, the FR protocol adds its local DLCI that received the ARP response to the ARP cache. Subsequent data packets directed to the same network address are then encapsulated into a frame and sent out over its local DLCI.
Protocol addresses can be either mapped statically to FR network PVC addresses or SVCs using locally configured names or discovered dynamically through Inverse ARP or ARP. (For more information on ARP and Inverse ARP, see the Protocol Configuration and Monitoring Reference.) Either method is protocol-dependent as illustrated in Table 57.
| Note: | Static protocol addresses are also referred to as static ARP entries. A static ARP entry is added to the configuration with the add protocol-address command. |
Table 57. Protocol Address Mapping
| Protocol Type | ARP and Inverse ARP Usage | Static Mapping | VC Configured at Protocol Configuration |
|---|---|---|---|
| AP2 | Yes | Yes | No |
| IP | Yes | Yes | No |
| IPX | Yes | Yes | No |
| Banyan VINES** | No | No | No |
| DNA IV | Yes | Yes | No |
| OSI*, ** | No | No | Yes |
| * You must configure OSI at the protocol level to map the protocol address to the FR PVC. | |||
| ** Not supported using SVCs. | |||
Multicast emulation is an optional feature that allows protocols requiring multicast such as ARP to function properly over the FR interface. With multicast emulation, a multicast frame is transmitted on each active PVC. By using the enable and disable multicast commands, you can turn this feature on or off. Protocols that utilize multicast are AP2, ARP, Banyan VINES, DNA4, IP, and IPX.
Protocol broadcast is another optional feature that allows the IP RIP protocol to function properly over the FR interface. By using the enable protocol-broadcast and disable protocol-broadcast commands, you can turn this feature on or off.
For protocols that support ARP/InARP over Frame Relay, Frame Relay will only multicast a protocols packets over a circuit if a protocol address was either learned or configured for that circuit.
Multicast can also be enabled or disabled for an individual SVC. Use the multicast option on add switched-virtual-circuit.
The supplier of the FR network backbone provides FR network management. It is management's responsibility to provide FR end-stations (routers) with status and configuration information concerning PVCs available at the interface.
For PVCs, the FR protocol supports the ANSI T1.617 Annex D, ITU-T Q.933 Annex A (also referred to as CCITT Q.933 Annex A), and the Interim Local Management Interface (LMI) management entities.
You can turn these entities on or off using the enable and disable LMI configuration commands. Specifically, FR LMI provides the following information:
Although the FR interface supports PVC network management, it is not necessary for management to run on the FR backbone for the interface to operate over the FR backbone. For example, you may want to disable management for back-to-back configurations.
For SVCs, the FR protocol supports FRF 4 (Frame Relay Forum Implementation Agreement 4). This includes an implementation of ANSI Q.922 and a subset of ANSI Q.933. Q.922 provides verification of the integrity of the physical link between the router and the network. Q.933 provides the means for establishing and disconnecting SVCs across the network. Q.922 and Q.933 are always enabled when SVCs are used.
Upon request, FR LMI provides two types of status reports, a full status report and a link integrity verification report. A full status report provides information about all PVCs the interface knows about. A link integrity verification report verifies the connection between a specific end station and a network switch. All status inquiries and responses are sent over DLCI 0 for ANSI T1.617 Annex D and ITU-T Q.933 Annex A, or DLCI 1023 for interim LMI management.
When the FR interface requires a full status report, the router's FR protocol sends a status enquiry message to the FR network backbone requesting a full status report. A status enquiry message is a request for the status of all PVCs on the interface. Upon receiving this request, FR management must respond with a full status report consisting of the link integrity verification element and a PVC status information element for each PVC. (See "Link Integrity Verification Report".)
The PVC status information element contains the following information: the local DLCI number for the particular PVC; the state of the PVC (active or inactive); and whether the PVC is new or an existing PVC that management already knows about.
| Note: | The number of PVCs supplied at the FR interface is restricted by the network frame size and the amount of individual PVC information elements that can fit into a full status report. For example, 202 is the maximum number of PVCs for a network with a 1K frame size. |
The link integrity verification report, sometimes referred to as heartbeat polling, contains the link integrity verification element. This element is where the exchange of the send and receive sequence numbers takes place. By exchanging sequence numbers, management and the end station can evaluate the integrity of the synchronous link. The send sequence number is the current send sequence number of the message originator. The receiver looks at this number and compares it to the last send sequence number to verify that this number is incrementally correct. The receive sequence number is the last send sequence number that the originator sent out over the interface. It is the receiver's responsibility to place a copy of the send sequence number into the receive sequence number field. This way the originator can ensure that the receiver receives and interprets the frames correctly.
When an end-station fails to participate in this polling process, all remote end-stations with logically attached PVCs are notified through management's full status report mechanism that the PVC is inactive.
CLLM is an optional FR management function that is not widely supported by the industry but it has been adopted by some Frame Relay switch manufacturers. CLLM provides some of the same management information provided by LMI, in particular, outage notification. CLLM's main use is to provide asynchronous congestion notification of PVCs to attaching devices. A single CLLM message may indicate outage or congestion for multiple PVCs. The Frame Relay protocol supports the following standards for CLLM: ANSI T1.618, ITU-T (CCITT) Q.922 Annex A, and ITU-T (CCITT) X.36 Annex C.
This section introduces data rates for Frame Relay permanent virtual circuits (PVCs).
The CIR is the data rate that the network commits to support for the VC under normal, uncongested conditions. Any VC that is configured or is learned is provided a CIR (by the FR service provider). The CIR is a portion of the total bandwidth of the physical link of either 0, or between 300 bps and 6 312 000 bps reserved for the VC. A value of 64 Kbps for a single DS0 channel is most common.
You define the CIR with the add permanent-virtual-circuit, change permanent-virtual-circuit, add switched-virtual-circuit, or change switched-virtual-circuit configuration command. You can also dynamically change the CIR with the set circuit console command. You can also set the default CIR for all Frame Relay circuits on this interface using the set CIR-defaults command.
Some Frame Relay switches allow a value of 0 to be configured for CIR. When CIR is equal to 0, little or no bandwidth is reserved in the Frame Relay network backbone for the VC, and the VC's traffic uses non-reserved bandwidth.
The router assigns a CIR to orphan circuits based on the CIR defaults configured at the interface level. If you are relying on the orphan circuit to route important data and the CIR, Bc, and Be values from the network provider are different from the values configured at the interface level, it is recommended that you define a PVC instead of an orphan circuit. Doing this, you can assign a CIR that the network commits to support.
The committed burst (Bc) size is the maximum amount of data (in bits) that the network commits to deliver during a calculated time (Tc) interval. The Tc is equal to the Bc divided by the CIR (Tc = Bc / CIR). If you configure 0 for CIR, Frame Relay uses a value of 1 second for Tc. .
For example, if you set a VC's CIR to 9600 bps and the committed burst size to 14 400 bits, the time period is 1.5 sec. (14 400 bits / 9600 bps = 1.5 sec). This means that the VC is allowed to transmit a maximum of 14 400 bits in 1.5 seconds.
| Note: | The minimum Tc supported by FR is .03 of a second. |
This parameter is important because of the relationship between the committed burst size and the maximum frame size. If the maximum frame size in bits is greater than the committed burst size, the network may discard frames whose size exceeds the committed burst size. Therefore, the committed burst size should be greater than or equal to the maximum frame size. It should also equal the burst size set up with the network provider.
Use the add permanent-virtual-circuit, change permanent-virtual-circuit, add switched-virtual-circuit or change switched-virtual-circuit configuration commands to set the committed burst size. The set circuit console command can be used to dynamically change the committed burst size. You can also set the default committed burst size for all Frame Relay circuits on this interface using the set CIR-defaults command.
The device assigns orphan circuits a committed burst size based on the default you set with the set CIR-defaults command. If you configure 0 for CIR, then the committed burst (Bc) size also equals 0.
The excess burst (Be) size is the maximum amount of uncommitted data the router can transmit on a PVC in excess of the Bc during the Tc (Tc = Bc / CIR) when CIR and Bc are nonzero. When CIR = 0, Frame Relay used a value of 1 second for Tc.
The network delivers this excess data with a lower probability of success than committed burst size data. Set the Be to a value greater than zero only if you are willing to accept the risk of discarded data and its effect on higher-layer protocol performance. The Be should equal the value set up with the network provider.
Use the add permanent-virtual-circuit, change permanent-virtual-circuit, add switched-virtual-circuit or change switched-virtual-circuit commands during frame-relay configuration to set the excess burst size. You can also use the set circuit console command to dynamically change the excess burst size. Orphan circuits will receive a default excess burst size equal to the value set in the set CIR-defaults command. If you configure 0 for CIR, then you must configure a nonzero value for the excess burst (Be) size. You can also set the default excess burst size for all Frame Relay circuits on this interface using the set CIR-defaults command.
The line speed is the interface's line speed.
The FR interface's line speed is configured using the set line-speed configuration command. The line speed must be configured when internal clocking is used. However, it is recommended that you configure a line speed for external clocking since the router uses the line speed as the maximum information rate when congestion monitoring is enabled. Also some of the protocols use an interface's configured line speed when calculating a route's cost.
The line speed is not configurable on a Frame Relay dial circuit interface. If the dial circuit is mapped to an ISDN base interface, 64 Kbps is used as the line speed.
For dial circuits using Channelized T1/E1 as the base net, the line speed is 64 Kbps times the number of timeslots assigned or 56 Kbps if you set the bandwidth of the Channelized circuit to 56 Kbps. For example, if you set the number of timeslots for a Channelized circuit to 3, the line speed is 192 Kbps (3 * 64 Kbps).
If the dial circuit is mapped to a V.25bis base interface, the line speed of the V.25bis interface is used for the FR dial circuit.
The minimum information rate (IR) is the minimum data rate for a VC that the router throttles down to when it is notified of congestion. You set the minimum IR as a percentage of CIR using the set ir-adjustment configuration command. It can be dynamically changed using the set ir-adjustment console command. If you configure CIR equal to 0, the minimum IR is 1500 bps.
The maximum information rate is the maximum data rate at which the router transmits for a VC. If the CIR monitoring feature is enabled and CIR and Bc are nonzero, the maximum information rate is calculated using CIR, Bc, and Be as follows:
( Bc + Be ) per Tc interval
If the CIR monitoring feature is enabled and CIR and Bc are configured equal to 0, the maximum information rate is equal to the excess burst size (Be) per second.
If the CIR monitoring feature is not enabled the maximum information rate is equal to the line speed.
The variable information rate (VIR) ranges from the configured minimum IR to the calculated maximum IR when the CIR monitoring or congestion monitoring features are enabled. The VIR is gradually decreased down to the minimum information rate when the router is notified of congestion on a circuit and is gradually increased to the maximum information rate when the router stops receiving congestion notifications. Using the set ir-adjustment configuration command, you configure the percentage of the information rate by which the VIR should decrease when the router is notified of congestion. You also use this command to configure the percentage of the information rate by which the VIR should be gradually increased when the congestion ends.
To avoid impulse loading of the network, the router initially sets the VIR to CIR when the VC becomes active. If you configure 0 for CIR, VIR is initially set to excess burst (Be) times the MIR adjustment percentage. For example, if Be is set to 64 000 and the MIR adjustment percentage is set to 25%, then the initial VIR would be equal to 16 000 bps.
The VIR can actually exceed the maximum value in one case. If the length of a frame in bits is greater than the maximum IR, Frame Relay transmits the frame anyway.
Circuit congestion occurs for one of the following reasons:
When circuit congestion happens, the network must drop packets and/or shut down.
In response to circuit congestion, the router implements a throttle down, which is a step-wise slowing of packet transmission to the configured minimum IR. Throttle down occurs during the following conditions:
This section discusses monitoring of Frame Relay data rates and circuit congestion.
CIR monitoring is an optional Frame Relay feature that you can set for each interface to prevent the router from creating congestion conditions in the FR network. CIR monitoring allows the VIR for a VC to range between the configured minimum and maximum IR.
CIR monitoring is configured with the enable cir-monitor configuration command and is disabled by default. CIR monitoring, when enabled, overrides congestion monitoring. You can also dynamically enable and disable CIR monitoring using the enable cir-monitor and disable cir-monitor console commands.
Congestion monitoring is an optional feature, set per interface, that allows the VIR of VCs to vary in response to network congestion. The VIR assumes values between the minimum IR and a maximum IR of the line speed. Congestion monitoring is enabled by default. It can be disabled with the disable congestion-monitor configuration command and re-enabled with the enable congestion-monitor command. You can also dynamically enable and disable congestion monitoring using the enable congestion-monitor and disable congestion-monitor console commands.
CIR monitoring, if enabled, overrides congestion monitoring. If both CIR monitoring and congestion monitoring are disabled, the VIR for each VC on the interface is set to the line speed and does not decrease in response to network congestion.
| Note: | Even with compression enabled, the device uses the uncompressed size of frames to determine if the VIR is being exceeded. |
When congestion occurs, the FR backbone network is responsible for notifying the sender and receiver by sending out a FECN or a BECN signal. FECN and BECN are bits that are set in a frame to notify the
DTEs at each end of a VC that congestion is occurring. FECN indicates that congestion is occurring in the same direction from which the frame was received; the sender is causing the congestion. BECN indicates that the frames sent by this DTE are causing network congestion.
Optionally, the network can use CLLM messages to convey congestion information for PVCs. CLLM messages are sent only to the congestion source and should be treated similarly to BECN messages by the DTE.
The example in Figure 25 shows a congestion condition at switch B when frames are sent from router X to router Y. The FR backbone network notifies router X that frames it sends are encountering congestion by setting the BECN bit in frames sent to router X. The FR backbone network also notifies router Y that frames it receives encountered congestion by setting the FECN bit.
When the router receives a frame containing BECN, it is the router's responsibility to throttle down the VC's VIR (variable information rate) if either CIR monitoring or congestion monitoring is enabled. The router does this gradually as it receives consecutive frames with BECN until either the minimum IR is reached or a frame without BECN arrives. FR switches often set BECN in multiple frames after reaching a congestion threshold. In order for FR to avoid overreacting to network congestion when the network is setting multiple frames with BECN, FR will decrease a VC's VIR at most once every second. This allows the VIR to decrease gradually. As the router receives consecutive frames without BECN, the VIR gradually rises to the maximum IR.
Depending on the operation of the FR network, it may be necessary for the device to throttle down the VC's VIR when the device receives a FECN to minimize the overall amount of traffic being offered to the network as quickly as possible. Reducing the overall load on the network reduces the number of packets discarded for all VCs to relieve congestion. Enabling the throttle-transmit-on-fecn parameter, along with either the CIR or congestion monitoring options, causes the device to treat a FECN like a BECN thus reducing overall FR network congestion when any congestion notification is received. Use the throttle-transmit-on-fecn parameter only in FR networks whose queuing methods do not provide dedicated buffers for both input and output. If the throttle-transmit-on-fecn is enabled, FR will decrease a VC's VIR at most once every second for each BECN or FECN received.
Some FR network switches set FECN to indicate congestion but do not set BECN. To provide congestion notification to the source of the congestion, enable the notify-fecn-source parameter allowing the device to set BECN in frames that it transmits over a VC on which it has received a FECN. This action provides a signal to the device that is causing the network congestion to throttle down its VC's VIR.
Figure 25. Congestion Notification and Throttle Down
| Note: | If multiple DLCIs are configured between two end-stations when congestion occurs, it is possible that a second DLCI may be used to transmit data at a higher throughput until the congestion condition on the first DLCI is corrected. |
Similarly, if the network provider supports CLLM, you can configure Frame Relay to throttle down its transmit rate for PVCs contained in a CLLM message. CLLM messages contain a cause code that indicates the type and severity of the problem being reported. The device reacts differently depending on the cause code and the CIR configured for each PVC contained in the CLLM message. When the device receives a CLLM message that indicates:
Once a CLLM message for a PVC has been received, if the device does not receive any CLLM messages or BECNs within the Ty timer period or if a frame without a BECN is received, the device will consider the congestion condition cleared and gradually return the PVC to its configured transmission rates. If you are using CLLM to control congestion, you must not configure DLCI 1007 for any other use.
For information on bandwidth reservation over Frame Relay, refer to "Using Bandwidth Reservation and Priority Queuing" and "Configuring and Monitoring Bandwidth Reservation" in Using and Configuring Features.
The bandwidth reservation system (BRS) should be configured to prioritize the data frame fragments if fragmentation is enabled on an interface. See Fragmentation Over a Frame Relay Interface.
Voice over Frame Relay (VoFR) is a method to transmit voice packets over a Frame Relay circuit. If you plan to use one Frame Relay circuit to carry both real-time (voice) and data traffic, you should configure that circuit to fragment the data traffic, especially if the link is relatively slow, for example, 64Kbps. Fragmentation is also needed for circuits on an interface that does not support voice if that interface exchanges with an interface that does support voice.
There are two types of fragmentation, end-to-end and interface (or UNI/NNI). Interface-level fragmentation has not been implemented by any major Frame Relay switch vendors and so it is not available from any Frame Relay service providers. Per the Frame Relay implementation agreement, FRF.12, end-to-end fragmentation is supported for PVCs only. Therefore, an interface with voice support can be used to support Frame Relay PVCs, but not SVCs.
You can configure the fragment sizes. Fragment sizes are not negotiated or communicated between interfaces and therefore may be different for two interconnected PVCs. The fragment size may vary from one link or PVC to another depending on the access speed of the link, the CIR of the PVC, and whether this interface is actually carrying real-time data or is communicating with another router whose interface is carrying real-time data. Other factors to consider when configuring fragmentation for voice over frame relay include committed burst size, BRS traffic classes and queue depths if BRS is configured, the number of global buffers created, and the number of receive buffers allocated to each interface.
Because of the overhead associated with fragmentation, it is best to keep the fragment size as large as possible while still maintaining high quality real-time data communications.
If a circuit transmits real-time data, you should configure the Bandwidth Reservation System (BRS) in addition to Frame Relay fragmentation on that interface and circuit. Enabling BRS can give higher priority to real-time data over other data. As a result, real-time data can be interleaved between other data that has been fragmented so that the queueing delay for the real-time data can be minimized.
BRS is required only for circuits that will actually be sending real-time data and other data. Other circuits on the interface, or circuits that communicate with interfaces that support real-time data, do not specifically need BRS support to allow interleaving.
Refer to the assign command in the chapter "Configuring and Monitoring Bandwidth Reservation" in the Using and Configuring Features for more information about configuring BRS.
| Note: | You can configure fragmentation either for an interface or for a circuit
(also called a PVC). If you configure fragmentation for a PVC, you must
use the add permanent-virtual-circuit or the change
permanent-virtual-circuit command. The following example shows
the add permanent-virtual-circuit command:
FR 1 Config>add perm 18 Committed Information Rate (CIR) in bps[64000]? Committed Burst Size (Bc)in bits [64000]? 4800 Excess Burst Size (Be) in bits [0]? Assign circuit name : :? VoFRcircuit1 Is circuit required for interface operation [N]? Enable circuit for voice forwarding [N]? Do you want to have end-to-end fragmentation performed [N]? y Fragment size (50 to 1000) [256]? Fragmented packet reassemby timer (3 to 10 seconds) [256]? |
Voice forwarding over Frame Relay will enable a voice- capable or non-voice capable router to forward FRF.11 encapsulated packets, that is, voice packets, between Frame Relay PVCs without using a native voice adapter. This will allow a voice-capable router to multiplex voice and data over the same virtual circuit across the Frame Relay network. The voice-forwarding router will then route the received data using the protocol stack associated with the received traffic and forward the voice traffic to another PVC over the same or another Frame Relay interface. In a typical configuration, the voice traffic is forwarded to a locally attached voice-capable device.
Even though it is a DCE-like function, voice packet forwarding will be done over virtual circuits defined as DTEs. Voice forwarding will be allowed for PVCs only because voice over Frame Relay is supported for PVCs only.
A PVC that will be used for voice packet forwarding must be enabled through configuration to do so. In fact, a pair of PVCs on assumedly different Frame Relay interfaces must be defined to forward voice packets to each other. When you enable a PVC for voice forwarding, you must provide the net number and DLCI of the PVC to which the PVC should forward the voice packets. Frame Relay will forward all voice packets between the pair of PVCs defined to do voice forwarding.
To access the Frame Relay configuration environment:
Config>network What is the network number [0] 2 Frame Relay user configuration FR 2 Config>
This section outlines the minimum configuration steps that you are required to perform to get the Frame Relay protocol up and running. If you desire any further configuration information and explanation, refer to the configuration commands described in this chapter.
| Note: | You must restart the router for new configuration changes to take effect. |
There are three management options under Frame Relay:
Frame Relay defaults to ANSI enabled. If you want to change management types, or if you want to re-enable ANSI management, use the following procedure. Enabling management over Frame Relay is a two-step process:
See Table 58 for details of the management types available using the set command.
An example of how to set these management types is shown after the table. Also, refer to the enable and set command sections in this chapter for more information.
Table 58. Frame Relay Management Options
| Command | Options | Description |
|---|---|---|
| set | lmi-type rev1 | Conforms to LMI Revision 1 (Stratacom s Frame Relay Interface Specification) |
| set | lmi-type ansi | Conforms to ANSI T1.617 ISDN-DSS1-Signalling Specification for Frame Relay Bearer Service (known as Annex D) |
| set | lmi-type ccitt | Conforms to Annex A of ITU-T/CCITT Recommendation Q.933 - DSS1 Signalling Specification for Frame Mode Basic Call Control. |
Frame Relay SVC management is automatically enabled when SVCs are enabled.